Tuple Space Middleware for Wireless Networks

Regions. Welsh et al. [23] propose a set of general-purpose communication primitives providing addressing, data sharing, and aggregation among a given subset of nodes. A region defines a neighborhood relationship between a specific node and other nodes in the system. For instance, a region can be defined to include all nodes within a given number of hops or within physical distance d. Data sharing is accomplished using a tuple space-like paradigm by giving developers language constructs to read/write 〈key,value〉 pairs at remote nodes. In a sense, this resembles the rd and out operations in traditional tuple space middleware, although the data format and matching is clearly much less expressive. Dedicated constructs are also provided to aggregate information stored at different nodes in a region. Moreover, a lightweight thread-like concurrency model, called Fibers, is provided for blocking operations. By their nature, Abstract Regions target applications exhibiting some form of spatial locality, e.g., tracking moving objects, or identifying the contours of physical regions. Agilla. The work in [24] presents a middleware system for WSNs that adopts a mobile agent paradigm [13]. Programs are composed of one or more software agents able to migrate across nodes. In a sense, an Agilla agent is similar to a virtual machine with its own instruction set and dedicated data/instruction memory. Coordina11.3 Wireless Sensor Networks 257 tion among agents is accomplished using a tuple space. Agents insert data in a local data pool to be read by different agents at later times. The data of interest is identified using a pattern matching mechanism, in a way similar to what is described in Section 11.1. In Agilla, the use of tuple spaces allows one to decouple the application logic residing in the agents from their coordination and communication. At the same time, tuple spaces also provide a way for agents to discover the surrounding context, e.g., by reading tuples describing the most recent sensed values. Reactive applications requiring on-the-fly reprogramming of sensor nodes (e.g., fire monitoring) are thus an ideal target scenario for Agilla. ATaG. The Abstract Task Graph (ATaG) [25] is a programming framework providing a mixed declarative-imperative approach. The notions of abstract task and abstract data item are at the core of the ATaG programming model. A task is a logical entity encapsulating the processing of one or more data items, which represent the information. The flow of information between tasks is defined in terms of abstract channels used to connect each data item to the tasks that produce or consume it. To exchange data among tasks, programmers are provided with the abstraction of a shared data pool where tasks can output data or be asynchronously notified when some data of interest is available. This style of interaction is similar to tuple spaces for mobile networks when using reactive operations, as described in Section 11.2.2, although in ATaG this is limited to triggering notifications when other processes perform a write, and the data of interest is determined solely based on its type, rather than an arbitrary pattern. The ability to isolate different processing steps in different tasks makes ATaG suited to control applications requiring multi-stage processing, e.g., road traffic control [26]. FACTS. Terfloth et al. [27] propose a middleware platform inspired by logical reasoning in expert systems. In FACTS, modular pieces of processing instructions called rules describe how to handle information. These are specified using a dedicated language called RDL (ruleset definition language), whereas data is specified in a special format called a fact. The appearance of new facts trigger the executions of one or more rules, that may generate new facts or remove existing ones. Facts can be shared among different nodes. The basic communication primitives in FACTS provide one-hop data sharing. Facts are reminiscent of tuples as a way of structuring the application data, while the triggering of rules in response to new facts is similar to the execution of reactions in mobile tuple space middleware. Reactive applications such as fence monitoring [28] are easily implemented using FACTS, thanks to the condition-action rules programmers can specify. Hood. The programming primitives provided by Hood [29] revolve around the notion of neighborhood. Constructs are provided to identify a subset of a node’s physical neighbors based on application criteria, and to share data with them. A node exports information in the form of attributes. Membership in a programmer-specified neighborhood is determined using filters. These are boolean functions that examine a node’s attributes and determine, based on their values, whether the remote node is to become part of the considered subset. If so, a mirror for that particular neighbor is created on the local node. The mirror contains both reflections, i.e., lo258 11 Tuple Space Middleware for Wireless Networks Abstract Regions [23] Agilla [24] ATaG [25] FACTS [27] Hood [29] TeenyLIME [30]Regions [23] Agilla [24] ATaG [25] FACTS [27] Hood [29] TeenyLIME [30] Reactive vs. Proactive Proactive Both Reactive Reactive Proactive Both Push vs. Pull Push Both Push Push Push Both Data Filtering Shared variables Pattern matching Named channels Fact constraints Applicationlevel filtering Pattern matching w/ value constraints Data Processing Reduce operator N/A N/A N/A N/A N/A Scope Programmerdefined Local Programmerdefined One-hop One-hop One-hop Table 11.2 Features of tuple space systems for wireless sensor networks. cal copies of the neighbor’s attributes that can be used to access the shared data, and scribbles, which are local annotations about a neighbor. Hood can be seen as a tuple space system where out operations are used to replicate local information on neighboring nodes, and filters take care of the matching functionality. Thanks to the support of multiple independent neighborhoods, Hood is applicable in diverse settings ranging from target tracking applications to localization mechanisms and MAC protocols [29]. TeenyLIME. Inspired by LIME, TeenyLIME [30] offers a Linda-like interface to programmers. To make the tuple space paradigm blend better with the asynchronous programming model of most WSN operating systems (e.g., TinyOS [31]), operations are non-blocking and return their results through a callback. In TeenyLIME, tuples are shared among neighboring nodes. Reactions are provided to allow for asynchronous notifications in case some specific piece of data appears in the shared tuple space. In addition, several WSN-specific features are made available to better address the requirements of sensor network applications. For instance, a notion of capability tuple is provided to enable on-demand sensing. This can save the energy required to keep sensed information up to date in the shared tuple space in the absence of any data consumer. Similarly to Hood, TeenyLIME reaches into the entire stack, providing constructs to develop full-fledged applications as well as systemlevel mechanisms, e.g., routing protocols. However, TeenyLIME specifically targets sense-and-react applications, (e.g., HVAC in buildings [32]), where its reactive and WSN-specific features provide a significant asset.